1. Field of the Invention
The present invention relates to a method of operating a virtual machine including an interpreter to provide trace information.
2. Description of the Related Art
Programs written in the Java programming language (Java is a trademark of Sun Microsystems Inc) are generally run in a virtual machine environment, rather than directly on hardware. Thus a Java program is typically compiled into byte-code form, and then interpreted by the Java virtual machine (JVM) into hardware commands for the platform on which the JVM is executing. The JVM itself is an application running on the underlying operating system. An important advantage of this approach is that Java applications can run on a very wide range of platforms, providing of course that a JVM is available for each platform.
Java is an object-oriented language. Thus a Java program is formed from a set of class files having methods that represent sequences of instructions (somewhat akin to subroutines). A hierarchy of classes can be defined, with each class inheriting properties (including methods) from those classes (termed superclasses) which are above it in the hierarchy. At run-time objects are created as instantiations of these class files, and indeed the class files themselves are effectively objects. One Java object can call a method in another Java object. In recent years Java has become very popular, and is described in many books, for example xe2x80x9cExploring Javaxe2x80x9d by Niemeyer and Peck, O""Reilly and Associates, 1996, USA, and xe2x80x9cThe Java Virtual Machine Specificationxe2x80x9d by Lindholm and Yellin, Addison-Wedley, 1997, USA.
In a general sense the running of a Java program represents a succession of Java method calls. The ability to track or monitor these method calls is very important to a Java programmer for diagnostic and debugging purposes. A conventional JVM supports a runtime option for tracing Java method calls: xe2x80x9cjava -Xtmxe2x80x9d, Runtime.traceMethodCalls( ). However, this is both slow and cumbersome, in that every single method call is traced directly to the standard output (stout). The result is something that is unusable in a production environment. It is also possible to turn this tracing on and off within Java programs, but again the results are all or nothing. Even a very simple program can result in thousands of lines of trace information.
It is also known to add specific output instructions to the Java application code; this output can then be used for tracing purposes at the relevant locations. This code then be switched on and off, for example dependent on some runtime setting. However, the output from such solutions is typically non-binary (i.e. slow), and it is also no good for tracing system classes or those classes for which source is unavailable.
A rather different approach is described in xe2x80x9cThe Tracing JVMxe2x80x9d by Mario Wolczko (http://www.sun.com/research/people/mario/tracing-jvm/) and pages referenced therein. This paper describes a significantly modified JVM which traces a predetermined set of events to indicate how objects, stacks and classes are being manipulated. A user can provide an external file to specify those events of interest from the predetermined set of events. The very low level output is perhaps better regarded as profiling rather than tracing information (i.e. more relevant to understanding overall application behaviour rather than specific diagnostics). The modifications to the JVM are sufficiently extensive that the whole performance characteristics of the JVM are modified; therefore the information provided is not useful for understanding performance questions.
In summary therefore, the prior art does not provide a tracing tool for the JVM which provides targeted data, and which can be used with arbitrary applications in a realistic or possibly even production environment.
Accordingly, the present invention provides a method of operating a virtual machine including an interpreter in an object-oriented system to provide trace information about specific method calls, said method comprising the steps of:
providing a selection of methods to be traced from a program;
running the program on the interpreter;
for each method call in the program, determining whether or not the method is included within said selection; and
for those methods which are determined to be included within said selection, outputting trace information about the method call.
The invention exploits the fact that a virtual machine is implemented in software, and so can be configured to provide trace information for the virtual machine environment. The most widespread use of such technology is likely to be in Java, in order to assist in the development of both Java applications, and also those system parts of the JVM which are themselves written in Java (such as class libraries, etc). A user can specify particular trace information of interest, and the interpreter can then track for each called method whether or not trace information is to be provided. The provision of targeted trace information avoids the system having to output large quantities of irrelevant information, thereby greatly assisting in performance. This in turn increases the value of the trace information, since it mirrors much more closely what occurs in a production environment; indeed, the trace information may itself be obtained from a production environment. This is assisted by the fact that the trace operation is enabled by the virtual machine, rather than the application program, so that source code and the ability to recompile are not required.
In a preferred embodiment, there is a method block associated with each method which is used by the interpreter to invoke the method. For each method that is included within said selection, a flag is set within the method block associated with the method. When the interpreter invokes a method using its method block, the status of the flag is checked in order to determine whether or not the method is included within the selection. If so, the interpreter provides trace information for output. In one preferred embodiment the flag comprises multiple bits. This then allows the user to indicate the type of trace information required for any particular method (eg method name, parameter values, parameter types, etc).
Typically the provision of the selection of methods for tracing is performed by creating a table of method calls to be traced. The flags in the method block can then be set in accordance with those method calls included within the table.
One complication is that in Java at least, it is relatively common to use JIT compiled code, which bypasses the interpreter. In such a situation the code for at least some method calls is compiled prior to running the program. In accordance with a preferred aspect of the present invention, during the compiling step, code for outputting trace information is included in those method calls selected by a user. Thus in this case it is (JIT) compiler changes rather than interpreter changes which support the selected provision of trace information.
The invention further provides a computer program product, comprising computer program instructions typically recorded onto a storage medium or transmitted over a network, for implementing the above methods.
The invention further provides an object-oriented system including a virtual machine that provides trace information about specific method calls, said system comprising:
a table specifying methods to be traced from a program;
an interpreter for running the program;
means for determining for each method call in the program whether or not the method is included within said selection; and
a diagnostics unit for outputting trace information about a method call for those methods which are determined to be included within said selection.